This pull request explores an option to render a block's controls in its edit implementation.

Benefits:

• The current controls callbacks have no access to the edit component instance, so in the case of proper component classes, they cannot make use of component state
• Controls are not inherent to the concept of a block. More precisely they are a concern of the block's rendering in the visual editor, reflected here in the return value of edit
• We do not need to create a separate argument signature for isActive and onClick callbacks, since it's easy enough to bind use attributes and setAttributes from the bound component instance or rendering scope.

Downsides:

• Requires block implementer to concern themselves with focus to ensure controls are only rendered if the block is currently selected
• It is not well-settled the extent to which we want to lean on the Slot-Fill pattern, which this uses

For related discussion, see also #717 (comment).

Open questions:

• Would we care to have <BlockControls /> as an additional layer when the block implementer could as easily render the <Fill /> directly?
• Since the implementation is supported already via the Formatting.Controls slot, do we care to make this the preferred approach if we could support both just the same? Could be nice to consolidate, but only if it's not viewed as more complex.
• We could abuse React's context feature to transparently pass the block's uid from VisualEditorBlock to BlockControls directly, bypassing the need for the block implementer to concern themselves with whether the block is currently selected, at the cost of reducing transparency

Testing instructions:

Ensure that heading block controls are shown and behave the same as in master. Only the heading block has been ported in this demonstration.